home *** CD-ROM | disk | FTP | other *** search
/ The Hacker Chronicles - A…the Computer Underground / The Hacker Chronicles - A Tour of the Computer Underground (P-80 Systems).iso / network / uucp.faq < prev    next >
Text File  |  1992-09-06  |  36KB  |  777 lines

  1. Here is a FAQ posting that I have worked up.  It is intended to answer
  2. most questions about how UUCP works, what the UUCP protocols are,
  3. etc., in nauseating detail.  It does not answer such useful questions
  4. as how to configure UUCP, how to make an X.25 PAD not trap ^P, etc.,
  5. and other questions for which I am not necessarily qualified to
  6. provide answers.  Let this posting serve as a challenge to other
  7. people to produce more FAQ answers, which can either be folded into
  8. this posting, or, more likely, form a separate posting.
  9.  
  10. This is the first trial of this posting.  I'll consider any comments,
  11. make a relatively final version, and start posting it every month.
  12. Enjoy!
  13.  
  14. Frequently Asked Questions about UUCP internals
  15. Last updated 1992-02-25
  16.  
  17. This article was written by Ian Lance Taylor <ian@airs.com> and I may
  18. even update it periodically.  Send me mail about suggestions or
  19. inaccuracies.
  20.  
  21. This article describes how the various UUCP protocols work.  It does
  22. not describe how to configure UUCP, nor how to solve UUCP problems,
  23. nor how to deal with UUCP mail.  There are currently no FAQ postings
  24. on any of these topics, and I do not plan to write any.
  25.  
  26. If you haven't read the news.announce.newusers articles, read them.
  27.  
  28. I took a lot of the information from Jamie E. Hanrahan's paper in the
  29. Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
  30. O'Reilly and Grace Todino (with contributions by several other
  31. people).  The latter includes most of the former, and is published by
  32.         O'Reilly & Associates, Inc.
  33.         632 Petaluma Avenua
  34.         Sebastopol, CA 95472
  35. It is currently in its tenth edition.  The ISBN number is
  36. 0-937175-48-X.
  37.  
  38. Some information is originally due to a Usenet article by Chuck
  39. Wegrzyn.  The information on the 'g' protocol comes partially from a
  40. paper by G.L. Chesson of Bell Laboratories, partially from Jamie E.
  41. Hanrahan's paper, and partially from source code by John Gilmore.  The
  42. information on the 'f' protocol comes from the source code by Piet
  43. Berteema.  The information on the 't' protocol comes from the source
  44. code by Rick Adams.  The information on the 'e' protocol comes from a
  45. Usenet article by Matthias Urlichs.
  46.  
  47. This article answers the following questions.  If one of these
  48. questions is posted to comp.mail.uucp, you are encouraged to send mail
  49. to the poster referring her or him to this FAQ.  There is no reason to
  50. post a followup, as most of us know the answer already.
  51.  
  52. *) What is the UUCP protocol?
  53. *) What is the 'g' protocol?
  54. *) What is the 'f' protocol?
  55. *) What is the 't' protocol?
  56. *) What is the 'e' protocol?
  57. *) What is the 'x' protocol?
  58.  
  59. *) What is the UUCP protocol?
  60.  
  61. The UUCP protocol is a conversation between two UUCP packages.  A UUCP
  62. conversation consists of three parts: an initial handshake, a series
  63. of file transfer requests, and a final handshake.
  64.  
  65. Before the initial handshake, the caller will usually have logged in
  66. the called machine and somehow started the UUCP package there.  On
  67. Unix this is normally done by setting the shell of the login name used
  68. to /usr/lib/uucp/uucico.
  69.  
  70. All messages in the initial handshake begin with a ^P (a byte with the
  71. octal value \020) and end with a null byte (\000).
  72.  
  73. The initial handshake goes as follows.  It is begun by the called
  74. machine.
  75.  
  76. called: \020Shere=hostname\000
  77.     The hostname is the UUCP name of the called machine.  Older UUCP
  78.     packages do not output it, and simply send \020Shere\000.
  79.  
  80. caller: \020Shostname options\000
  81.     The hostname is the UUCP name of the calling machine.  The
  82.     following options may appear (or there may be none):
  83.         -QSEQ
  84.             Report sequence number for this conversation.  The
  85.             sequence number is stored at both sites, and incremented
  86.             after each call.  If there is a sequence number mismatch,
  87.             something has gone wrong (somebody may have broken
  88.             security by pretending to be one of the machines) and the
  89.             call is denied.
  90.         -xLEVEL
  91.             Requests the called system to set its debugging level to
  92.             the specified value.  This is not supported by all
  93.             systems.
  94.         -pGRADE
  95.         -vgrade=GRADE
  96.             Requests the called system to only transfer files of the
  97.             specified grade or higher.  This is not supported by all
  98.             systems.  Some systems support -p, some support -vgrade=.
  99.         -R
  100.             Indicates that the calling UUCP understands how to restart
  101.             failed file transmissions.  Supported only by System V
  102.             Release 4 UUCP.
  103.         -ULIMIT
  104.             Reports the ulimit value of the calling UUCP.  The limit
  105.             is specified as a base 16 number in C notation (e.g.
  106.             -U0x1000000).  This number is the number of 512 byte
  107.             blocks in the largest file which the calling UUCP can
  108.             create.  The called UUCP may not transfer a file larger
  109.             than this.  Supported only by System V Release 4 UUCP.
  110.         -N
  111.             Indicates that the calling UUCP understands the Taylor
  112.             UUCP size limiting extensions.  Supported only by Taylor
  113.             UUCP.
  114.  
  115. called: \020ROK\000
  116.     There are actually several possible responses.
  117.         ROK
  118.             The calling UUCP is acceptable, and the handshake proceeds
  119.             to the protocol negotiation.  Some options may also
  120.             appear; see below.
  121.         ROKN
  122.             The calling UUCP is acceptable, it specified -N, and the
  123.             called UUCP understands the Taylor UUCP size limiting
  124.             extensions.  Supported only by Taylor UUCP.
  125.         RLCK
  126.             The called UUCP already has a lock for the calling UUCP,
  127.             which normally indicates the two machines are already
  128.             communicating.
  129.         RCB
  130.             The called UUCP will call back.  This may be used to avoid
  131.             impostors (but only one machine out of each pair should
  132.             call back, or no conversation will ever begin).
  133.         RBADSEQ
  134.             The call sequence number is wrong (see the -Q discussion
  135.             above).
  136.         RLOGIN
  137.             The calling UUCP is using the wrong login name.
  138.         RYou are unknown to me
  139.             The calling UUCP is not known to the called UUCP, and the
  140.             called UUCP does not permit connections from unknown
  141.             systems.
  142.     If the response is ROK, the following options are supported by
  143.     System V Release 4 UUCP.
  144.         -R
  145.             The called UUCP knows how to restart failed file
  146.             transmissions.
  147.         -ULIMIT
  148.             Reports the ulimit value of the called UUCP.  The limit is
  149.             specified as a base 16 number in C notation.  This number
  150.             is the number of 512 byte blocks in the largest file which
  151.             the called UUCP can create.  The calling UUCP may not send
  152.             a file larger than this.
  153.         -xLEVEL
  154.             I'm not sure about this one.  It may request the calling
  155.             UUCP to set its debugging level to the specified value.
  156.     If the response is not ROK (or ROKN) both sides hang up the phone,
  157.     abandoning the call.
  158.  
  159. called: \020Pprotocols\000
  160.     Note that the called UUCP outputs two strings in a row.  The
  161.     protocols string is a list of UUCP protocols supported by the
  162.     caller.  Each UUCP protocol has a single character name.  These
  163.     protocols are discussed in more detail later in this document.
  164.     For example, the called UUCP might send \020Pgf\000.
  165.  
  166. caller: \020Uprotocol\000
  167.     The calling UUCP selects which protocol to use out of the
  168.     protocols offered by the called UUCP.  If there are no mutually
  169.     supported protocols, the calling UUCP sends \020UN\000 and both
  170.     sides hang up the phone.  Otherwise the calling UUCP sends
  171.     something like \020Ug\000.
  172.  
  173. At this point the initial handshake has been completed, and both sides
  174. turn on the selected protocol.  For some protocols (notably 'g') a
  175. further handshake is done at this point.
  176.  
  177. Each protocol supports a method for sending a command to the remote
  178. system.  This method is used to transmit a series of commands between
  179. the two UUCP packages.  At all times, one package is the master and
  180. the other is the slave.  Initially, the calling UUCP is the master.
  181.  
  182. If a protocol error occurs during the exchange of commands, both sides
  183. move immediately to the final handshake.
  184.  
  185. The master will send one of four commands: S, R, X or H.
  186.  
  187. Any file name referred to below is either an absolute pathname
  188. beginning with "/", a public directory pathname beginning with "~/", a
  189. pathname relative to a user's home directory beginning with "~USER/",
  190. or a spool directory file name.  File names in the spool directory are
  191. not pathnames, but instead are converted to pathnames within the spool
  192. directory by UUCP.  They always begin with "C." (for a command file
  193. created by uucp or uux), "D." (for a data file created by uucp, uux or
  194. by an execution, or received from another system for an execution), or
  195. "X." (for an execution file created by uux or received from another
  196. system).
  197.  
  198. master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE
  199.     The S and the - are literal characters.  This is a request by the
  200.     master to send a file to the slave.
  201.         FROM
  202.             The name of the file to send.  If the C option does not
  203.             appear in OPTIONS, the master will actually open and send
  204.             this file.  Otherwise the file has been copied to the
  205.             spool directory, where it is named TEMP.  The slave
  206.             ignores this field unless TO is a directory, in which case
  207.             the basename of FROM will be used as the file name.  If
  208.             FROM is a spool directory filename, it must be a data file
  209.             created for or by an execution, and must begin with "D.".
  210.         TO
  211.             The name to give the file on the slave.  If this field
  212.             names a directory (a name ending in '/' is taken to name a
  213.             directory even if one does not already exist with that
  214.             name) the file is placed within that directory with the
  215.             basename of FROM.  If TO begins with "X.", an execution
  216.             file will be created on the slave.  Otherwise, if TO
  217.             begins with "D." it names a data file to be used by some
  218.             execution file.  Otherwise, TO may not be in the spool
  219.             directory.
  220.         USER
  221.             The name of the user who requested the transfer.
  222.         OPTIONS
  223.             A list of options to control the transfer.  The following
  224.             options are defined (all options are single characters):
  225.                 C
  226.                     The file has been copied to the spool directory
  227.                     (the master should use TEMP rather than FROM).
  228.                 c
  229.                     The file has not been copied to the spool
  230.                     directory (this is the default).
  231.                 d
  232.                     The slave should create directories as necessary
  233.                     (this is the default).
  234.                 f
  235.                     The slave should not create directories if
  236.                     necessary, but should fail the transfer instead.
  237.                 m
  238.                     The master should send mail to USER when the
  239.                     transfer is complete.
  240.                 n
  241.                     The slave should send mail to NOTIFY when the
  242.                     transfer is complete.
  243.         TEMP
  244.             If the C option appears in OPTIONS, this names the file to
  245.             be sent.  Otherwise if FROM is in the spool directory,
  246.             TEMP is the same as FROM.  Otherwise TEMP is a dummy
  247.             string, normally "D.0".  After the transfer has been
  248.             succesfully completed, the master will delete the file
  249.             TEMP.
  250.         MODE
  251.             This is an octal number giving the mode of the file on
  252.             MASTER.  If the file is not in the spool directory, the
  253.             slave will always create it with mode 0666, except that if
  254.             (MODE & 0111) is not zero (the file is executable), the
  255.             slave will create the file with mode 0777.  If the file is
  256.             in the spool directory, some UUCP packages will use the
  257.             algorithm above and some will always create the file with
  258.             mode 0600.
  259.         NOTIFY
  260.             This field is only present if the n option appears in
  261.             OPTIONS.  When the transfer is successfully completed, the
  262.             slave will send mail to NOTIFY, which must be a legal
  263.             mailing address on the slave.  If a SIZE field will appear
  264.             but the n option does not appear, NOTIFY will be the
  265.             string "dummy" or simply a pair of double quotes.
  266.         SIZE
  267.             This field is only present when doing size negotiation,
  268.             either with Taylor UUCP or SVR4 UUCP.  It is the size of
  269.             the file in bytes.  SVR4 UUCP sends the size in base 16 as
  270.             0x.... while Taylor UUCP sends the size as a decimal
  271.             integer.
  272.  
  273.     The slave then responds with an S command response.
  274.         SY START
  275.             The slave is willing to accept the file, and file transfer
  276.             begins.  The START field will only be present when using
  277.             SVR4 file restart.  It specifies the byte offset into the
  278.             file at which to start sending.  If this is a new file,
  279.             START will be 0x0.
  280.         SN2
  281.             The slave denies permission to transfer the file.  This
  282.             can mean that the destination directory may not be
  283.             accessed, or that no requests are permitted.  It implies
  284.             that the file transfer will never succeed.
  285.         SN4
  286.             The slave is unable to create the necessary temporary
  287.             file.  This implies that the file transfer may succeed
  288.             later.
  289.         SN6
  290.             This is only used by Taylor UUCP size negotiation.  It
  291.             means that the slave considers the file too large to
  292.             transfer at the moment, but it may be possible to transfer
  293.             it at some other time.
  294.         SN7
  295.             This is only used by Taylor UUCP size negotiation.  It
  296.             means that the slave considers the file too large to ever
  297.             transfer.
  298.  
  299.     If the slave responds with SY, a file transfer begins.  When the
  300.     file transfer is complete, the slave sends a C command response.
  301.         CY
  302.             The file transfer was successful.
  303.         CN5
  304.             The temporary file could not be moved into the final
  305.             location.  This implies that the file transfer will never
  306.             succeed.
  307.  
  308.     After the C command response has been received (in the SY case) or
  309.     immediately (in an SN case) the master will send another command.
  310.  
  311. master: R FROM TO USER -OPTIONS SIZE
  312.     The R and the - are literal characters.  This is a request by the
  313.     master to receive a file from the slave.  I do not know how SVR4
  314.     UUCP implements file transfer restart in this case.
  315.         FROM
  316.             This is the name of the file on the slave which the master
  317.             wishes to receive.  It must not be in the spool directory,
  318.             and it may not contain any wildcards.
  319.         TO
  320.             This is the name of the file to create on the master.  I
  321.             do not believe that it can be a directory.  It may only be
  322.             in the spool directory if this file is being requested to
  323.             support an execution either on the master or on some
  324.             system other than the slave.
  325.         USER
  326.             The name of the user who requested the transfer.
  327.         OPTIONS
  328.             A list of options to control the transfer.  The following
  329.             options are defined (all options are single characters):
  330.                 d
  331.                     The master should create directories as necessary
  332.                     (this is the default).
  333.                 f
  334.                     The master should not create directories if
  335.                     necessary, but should fail the transfer instead.
  336.                 m
  337.                     The master should send mail to USER when the
  338.                     transfer is complete.
  339.         SIZE
  340.             This only appears if Taylor UUCP size negotiation is being
  341.             used.  It specifies the largest file which the master is
  342.             prepared to accept (when using SVR4 UUCP, this was
  343.             specified in the -U option during the initial handshake).
  344.  
  345.     The slave then responds with an R command response.
  346.         RY MODE
  347.             The slave is willing to send the file, and file transfer
  348.             begins.  MODE is the octal mode of the file on the slave.
  349.             The master treats this just as the slave does the MODE
  350.             argument in the send command, q.v.
  351.         RN2
  352.             The slave is not willing to send the file, either because
  353.             it is not permitted or because the file does not exist.
  354.             This implies that the file request will never succeed.
  355.         RN6
  356.             This is only used by Taylor UUCP size negotiation.  It
  357.             means that the file is too large to send, either because
  358.             of the size limit specifies by the master or because the
  359.             slave considers it too large.  The file transfer may
  360.             succeed later, or it may not (this will be cleared up in a
  361.             later release of Taylor UUCP).
  362.  
  363.     If the slave responds with RY, a file transfer begins.  When the
  364.     file transfer is complete, the master sends a C command.  The
  365.     slave pretty much ignores this, although it may log it.
  366.         CY
  367.             The file transfer was successful.
  368.         CN5
  369.             The temporary file could not be moved into the final
  370.             location.
  371.  
  372.     After the C command response has been sent (in the RY case) or
  373.     immediately (in an RN case) the master will send another command.
  374.  
  375. master: X FROM TO USER -OPTIONS
  376.     The X and the - are literal characters.  This is a request by the
  377.     master to, in essence, execute uucp on the slave.  The slave
  378.     should execute "uucp FROM TO".
  379.         FROM
  380.             This is the name of the file or files on the slave which
  381.             the master wishes to transfer.  It will often contain
  382.             wildcard characters, since otherwise an R command will
  383.             normally suffice (however, this command can also be used
  384.             to request the transfer of a file on the slave to a third
  385.             system).  Any wildcards should be expanded on the slave.
  386.         TO
  387.             This is the name of the file or directory to which the
  388.             files should be transferred.  This will normally use a
  389.             UUCP name.  For example, if the master wishes to receive
  390.             the files itself, it would use "master!path".
  391.         USER
  392.             The name of the user who requested the transfer.
  393.         OPTIONS
  394.             A list of options to control the transfer.  It is not
  395.             clear which, if any, options are supported by most UUCP
  396.             packages.
  397.  
  398.     The slave then responds with an X command response.
  399.         XY
  400.             The request was accepted, and the appropriate file
  401.             transfer commands have been queued up for later
  402.             processing.
  403.         XN
  404.             The request was denied.  No particular reason is given.
  405.  
  406.     In either case, the master will then send another command.
  407.  
  408. master: H
  409.     This is used by the master to hang up the connection.  The slave
  410.     will respond with an H command response.
  411.         HY
  412.             The slave agrees to hang up the connection.  In this case
  413.             the master sends another HY command.  In some UUCP
  414.             packages the slave will then send a third HY command.  At
  415.             this point the protocol is shut down, and the final
  416.             handshake is begun.
  417.         HN
  418.             The slave does not agree to hang up.  In this case the
  419.             master and the slave exchange roles.  The next command
  420.             will be sent by the former slave, which is the new master.
  421.             The roles may be reversed several times during a single
  422.             connection.
  423.  
  424. After the protocol has been shut down, the final handshake is
  425. performed.  This handshake has no real purpose, and some UUCP packages
  426. simply drop the connection rather than do it (in fact, some will drop
  427. the connection immediately after both sides agree to hangup, without
  428. even closing down the protocl).
  429.  
  430. caller: \020OOOOOO\000
  431. called: \020OOOOOOO\000
  432.  
  433. That is, the calling UUCP sends six O's and the called UUCP replies
  434. with seven O's.  Some UUCP packages always send six O's.
  435.  
  436. *) What is the 'g' protocol?
  437.  
  438. The 'g' protocol is a packet based flow controlled error correcting
  439. protocol that requires an eight bit clear connection.  It is the
  440. original UUCP protocol, and is supported by all UUCP implementations.
  441. Many implementations of it are only able to support small window and
  442. packet sizes, specifically a window size of 3 and a packet size of 64
  443. bytes, but the protocol itself can support up to a window size of 7
  444. and a packet size of 4096 bytes.  Complaints about the inefficiency of
  445. the 'g' protocol generally refer to specific implementations, rather
  446. than the correctly implemented protocol.
  447.  
  448. The 'g' protocol was originally designed for general packet drivers,
  449. and thus contains some features that are not used by UUCP, including
  450. an alternate data channel and the ability to renegotiate packet and
  451. window sizes during the communication session.
  452.  
  453. The 'g' protocol is spoofed by many Telebit modems.  When spoofing is
  454. in effect, each Telebit modem uses the 'g' protocol to communicate
  455. with the attached computer, but the data between the modems is sent
  456. using a Telebit proprietary error correcting protocol.  This allows
  457. for very high throughput over the Telebit connection, which, because
  458. it is half-duplex, would not normally be able to handle the 'g'
  459. protocol very well at all.
  460.  
  461. This discussion of the 'g' protocol explains how it works, but does
  462. not discuss useful error handling techniques.  Some discussion of this
  463. can be found in Jamie E. Hanrahan's paper, cited above.
  464.  
  465. All 'g' protocol communication is done with packets.  Each packet
  466. begins with a six byte header.  Control packets consist only of the
  467. header.  Data packets contain additional data.
  468.  
  469. The header is as follows:
  470.  
  471.     \020
  472.         Every packet begins with a ^P.
  473.     k (1 <= k <= 9)
  474.         The k value is always 9 for a control packet.  For a data
  475.         packet, the k value indicates how must data follows the six
  476.         byte header.  The amount of data is 2 ** (k + 4), where **
  477.         indicates exponentiation.  Thus a k value of 1 means 32 data
  478.         bytes and a k value of 8 means 4096 data bytes.  The k value
  479.         for a data packet must be between 1 and 8 inclusive.
  480.     checksum low byte
  481.     checksum high byte
  482.         The checksum value is described below.
  483.     control byte
  484.         The control packet indicates the type of packet, and is
  485.         described below.
  486.     xor byte
  487.         This byte is the xor of k, the checksum low byte, the checksum
  488.         high byte and the control byte (i.e. the second, third, fourth
  489.         and fifth header bytes).  It is used to ensure that the header
  490.         data is valid.
  491.  
  492. The control byte in the header is composed of three bit fields,
  493. referred to here as TT (two bits), XXX (three bits) and YYY (three
  494. bits).  The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY.
  495.  
  496. The TT field takes on the following values:
  497.     0
  498.         This is a control packet.  In this case the k byte in the
  499.         header must be 9.  The XXX field indicates the type of control
  500.         packet; these types are described below.
  501.     1
  502.         This is an alternate data channel packet.  This is not used by
  503.         UUCP.
  504.     2
  505.         This is a data packet, and the entire contents of the attached
  506.         data field (whose length is given by the k byte in the header)
  507.         are valid.  The XXX and YYY fields are described below.
  508.     3
  509.         This is a short data packet.  Let the length of the data field
  510.         (as given by the k byte in the header) be L.  Let the first
  511.         byte in the data field be B1.  If B1 is less than 128 (if the
  512.         most significant bit of B1 is 0), then there are L - B1 valid
  513.         bytes of data in the data field, beginning with the second
  514.         byte.  If B1 >= 128, let B2 be the second byte in the data
  515.         field.  Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid
  516.         bytes of data in the data field, beginning with the third
  517.         byte.  In all cases L bytes of data are sent (and all data
  518.         bytes participate in the checksum calculation) but some of the
  519.         trailing bytes may be dropped by the receiver.   The XXX and
  520.         YYY fields are described below.
  521.  
  522. In a data packet (short or not) the XXX field gives the sequence
  523. number of the packet.  Thus sequence numbers can range from 0 to 7,
  524. inclusive.  The YYY field gives the sequence number of the last
  525. correctly received packet.
  526.  
  527. Each communication direction uses a window which indicates how many
  528. unacknowledged packets may be transmitted before waiting for an
  529. acknowledgement (the window may be different in each direction).  The
  530. window may range from 1 to 7. For example, if the window is 3 and the
  531. last packet acknowledged was packet number 6, packet numbers 7, 0 and
  532. 1 may be sent but the sender must wait for an acknowledgement before
  533. sending packet number 2.  This acknowledgement could come as the YYY
  534. field of a data packet or as the YYY field of a RJ or RR control
  535. packet (described below).
  536.  
  537. Each packet must be transmitted in order (the sender may not skip
  538. sequence numbers).  Each packet must be acknowledged, and each packet
  539. must be acknowledged in order.
  540.  
  541. In a control packet, the XXX field takes on the following values:
  542.     1 CLOSE
  543.         The connection should be closed immediately.  This is
  544.         typically sent when one side has seen too many errors and
  545.         wants to give up.  It is also sent when shutting down the
  546.         protocol.  If an unexpected CLOSE packet is received, a CLOSE
  547.         packet should be sent and the 'g' protocol should halt,
  548.         causing UUCP to enter the final handshake.
  549.     2 RJ or NAK
  550.         The last packet was not received correctly.  The YYY field
  551.         contains the sequence number of the last correctly received
  552.         packet.
  553.     3 SRJ
  554.         Selective reject.  The YYY field contains the sequence number
  555.         of a packet that was not received correctly, and should be
  556.         retransmitted.  This is not used by UUCP, and most
  557.         implementations will not recognize it.
  558.     4 RR or ACK
  559.         Packet acknowledgement.  The YYY field contains the sequence
  560.         number of the last correctly received packet.
  561.     5 INITC
  562.         Third initialization packet.  The YYY field contains the
  563.         maximum window size to use.
  564.     6 INITB
  565.         Second initialization packet.  The YYY field contains the
  566.         packet size to use.  It requests a size of 2 ** (YYY + 5);
  567.         note that this is not the same coding used for the k byte in
  568.         the packet header (it is 1 less).  Some UUCP implementations
  569.         can handle any packet size up to that specified; some can only
  570.         handled exactly the size specified.
  571.     7 INITA
  572.         First initialization packet.  The YYY field contains the
  573.         maximum window size to use.
  574.  
  575. The checksum of a control packet is simply 0xaaaa - the control byte.
  576.  
  577. The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte),
  578. where ^ denotes exclusive or, and CHECK is the result of the following
  579. routine as run on the contents of the data field (every byte in the
  580. data field participates in the checksum, even for a short data
  581. packet).  This is the routine used by Taylor UUCP, and is a slightly
  582. modified version of a routine which John Gilmore patched from G.L.
  583. Chesson's original paper.  The z argument points to the data and the c
  584. argument indicates how much data there is.
  585.  
  586. int
  587. igchecksum (z, c)
  588.      register const char *z;
  589.      register int c;
  590. {
  591.   register unsigned int ichk1, ichk2;
  592.  
  593.   ichk1 = 0xffff;
  594.   ichk2 = 0;
  595.  
  596.   do
  597.     {
  598.       register unsigned int b;
  599.  
  600.       /* Rotate ichk1 left.  */
  601.       if ((ichk1 & 0x8000) == 0)
  602.         ichk1 <<= 1;
  603.       else
  604.         {
  605.           ichk1 <<= 1;
  606.           ++ichk1;
  607.         }
  608.  
  609.       /* Add the next character to ichk1.  */
  610.       b = *z++ & 0xff;
  611.       ichk1 += b;
  612.  
  613.       /* Add ichk1 xor the character position in the buffer counting from
  614.          the back to ichk2.  */
  615.       ichk2 += ichk1 ^ c;
  616.  
  617.       /* If the character was zero, or adding it to ichk1 caused an
  618.          overflow, xor ichk2 to ichk1.  */
  619.       if (b == 0 || (ichk1 & 0xffff) < b)
  620.         ichk1 ^= ichk2;
  621.     }
  622.   while (--c > 0);
  623.  
  624.   return ichk1 & 0xffff;
  625. }
  626.  
  627. When the 'g' protocol is started, the calling UUCP sends an INITA
  628. control packet with the window size it wishes the called UUCP to use.
  629. The called UUCP responds with an INITA packet with the window size it
  630. wishes the calling UUCP to use.  Pairs of INITB and INITC packets are
  631. then similarly exchanged.  When these exchanges are completed, the
  632. protocol is considered to have been started.
  633.  
  634. When a UUCP package transmits a command, it sends one or more data
  635. packets.  All the data packets will normally be complete, although
  636. some UUCP packages may send a the last one as a short packet.  The
  637. UUCP package receiving the command will know when the command has
  638. finished because it will be terminated by a null byte sent as data.
  639. Some UUCP packages require the last byte of the last packet sent to be
  640. null, even if the command ends earlier in the packet.  Some packages
  641. may require all the trailing bytes in the last packet to be null, but
  642. I have not confirmed this.
  643.  
  644. When a UUCP package sends a file, it will send a sequence of data
  645. packets.  The end of the file is signalled by a short data packet
  646. containing zero valid bytes (it will normally be preceeded by a short
  647. data packet containing the last few bytes in the file).
  648.  
  649. Note that the sequence numbers cover the entire communication session,
  650. including both command and file data.
  651.  
  652. When the protocol is shut down, each UUCP package sends a CLOSE
  653. control packet.
  654.  
  655. *) What is the 'f' protocol?
  656.  
  657. The 'f' protocol is a seven bit protocol which checksums an entire
  658. file at a time.  It only uses the characters between \040 and \176
  659. (ASCII space and ~) inclusive as well as the carriage return
  660. character.  It can be very efficient for transferring text only data,
  661. but it is very inefficient at transferring eight bit data (such as
  662. compressed news).  It is not flow controlled, and the checksum is
  663. fairly insecure over large files, so using it over a serial connection
  664. requires handshaking (XON/XOFF can be used) and error correcting
  665. modems.  Some people think it should not be used even under those
  666. circumstances.
  667.  
  668. I believe the 'f' protocol originated in BSD versions of UUCP.  It was
  669. originally intended for transmission over X.25 PAD links.
  670.  
  671. The 'f' protocol has no startup or finish protocol.  However, both
  672. sides should sleep for a couple of seconds before starting up, because
  673. typically they will switch the terminal into XON/XOFF mode and want to
  674. allow the changes to settle before beginning transmission.
  675.  
  676. When a UUCP package transmits a command, it simply sends a string
  677. terminated by a carriage return.
  678.  
  679. When a UUCP package transmits a file, each byte b of the file is
  680. translated according to the following table:
  681.  
  682.        0 <= b <=  037: 0172, b + 0100 (0100 to 0137)
  683.      040 <= b <= 0171:       b        ( 040 to 0171)
  684.     0172 <= b <= 0177: 0173, b - 0100 ( 072 to  077)
  685.     0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
  686.     0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
  687.     0372 <= b <= 0377: 0176, b - 0300 ( 072 to  077)
  688.  
  689. That is, a byte between \040 and \171 inclusive is transmitted as is,
  690. and all other bytes are prefixed and modified as shown.
  691.  
  692. When all the file data is sent, a seven byte sequence is sent: two
  693. bytes of \176 followed by four ASCII bytes of the checksum as printed
  694. in base 16 followed by a carriage return.  For example, if the
  695. checksum was 0x1234, this would be sent: "\176\1761234\r".
  696.  
  697. The checksum is initialized to 0xffff.  For each byte that is sent it
  698. is modified as follows (where b is the byte before it has been
  699. transformed as described above):
  700.  
  701.       /* Rotate the checksum left.  */
  702.       if ((ichk & 0x8000) == 0)
  703.         ichk <<= 1;
  704.       else
  705.         {
  706.           ichk <<= 1;
  707.           ++ichk;
  708.         }
  709.  
  710.       /* Add the next byte into the checksum.  */
  711.       ichk += b;
  712.  
  713. When the receiving UUCP sees the checksum, it compares it against its
  714. own calculated checksum and replies with a single character followed
  715. by a carriage return.
  716.     G
  717.         The file was received correctly.
  718.     R
  719.         The checksum did not match, and the file should be resent from
  720.         the beginning.
  721.     Q
  722.         The checksum did not match, but too many retries have occurred
  723.         and the communication session should be abandoned.
  724.  
  725. The sending UUCP checks the returned character and acts accordingly.
  726.  
  727. *) What is the 't' protocol?
  728.  
  729. The 't' protocol is intended for TCP links.  It does no error checking
  730. or flow control, and requires an eight bit clear channel.
  731.  
  732. I believe the 't' protocol originated in BSD versions of UUCP.
  733.  
  734. When a UUCP package transmits a command, it first gets the length of
  735. the command string, C.  It then sends ((C / 512) + 1) * 512 bytes (the
  736. smallest multiple of 512 which can hold C bytes plus a null byte)
  737. consisting of the command string itself followed by trailing null
  738. bytes.
  739.  
  740. When a UUCP package sends a file, it sends it in blocks.  Each block
  741. contains at most 1024 bytes of data.  Each block consists of four
  742. bytes containing the amount of data in binary (most significant byte
  743. first, the same format as used by the Unix function htonl) followed by
  744. that amount of data.  The end of the file is signalled by a block
  745. containing zero bytes of data.
  746.  
  747. *) What is the 'e' protocol?
  748.  
  749. The 'e' protocol is similar to the 't' protocol.  It does no flow
  750. control or error checking and is intended for use over TCP.
  751.  
  752. The 'e' protocol originated in versions of HDB UUCP.
  753.  
  754. When a UUCP package transmits a command, it simply sends the command
  755. as an ASCII string terminated by a null byte.
  756.  
  757. When a UUCP package transmits a file, it sends the complete size of
  758. the file as an ASCII decimal number.  The ASCII string is padded out
  759. to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it
  760. sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0").  It then sends the
  761. entire file.
  762.  
  763. *) What is the 'x' protocol?
  764.  
  765. I believe that the 'x' protocol was intended for use over X.25 virtual
  766. circuits.  It relies on a write of zero bytes being read as zero bytes
  767. without stopping communication.  I have heard that it does not work
  768. correctly.  If someone would care to fill this in more, I would be
  769. grateful.
  770. --
  771. Ian Taylor                  ian@airs.com                  uunet!airs!ian
  772. First person to identify this quote wins a free e-mail message:
  773. ``The will to be stupid is a very powerful force.''
  774.  
  775. Downloaded From P-80 Systems 304-744-2253
  776.  
  777.